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Abstract 

Remote procedure calls are computationally expensive, because 
network round-trips take several orders of magnitude longer than 
local interactions. One common technique for amortizing this cost 
is to batch together multiple independent requests into one com¬ 
pound request. Batching requests amounts to serializing the ab¬ 
stract syntax tree of a small program, in order to transmit it and 
run it remotely. The standard representation for abstract syntax is 
to use free monads', we show that free applicative functors are ac¬ 
tually a better choice of representation for this scenario. 

Categories and Subject Descriptors C.2.4 [Distributed Systems ]: 
Distributed applications; D.3.2 [Language Classifications ]: Func¬ 
tional languages; F.3.2 [Semantics of Programming Languages ]: 
Algebraic approaches to semantics 

Keywords Remote procedure call, batched request, free monad, 
free applicative functor 

1. Introduction 

Distributed computing is hard. Peter Deutsch famously codified a 
number of fallacies of distributed computing (Deutsch 1994) con¬ 
cerning issues such as reliability, cost, and heterogeneity, which 
together make distributed systems trickier to get right than cen¬ 
tralized systems. Distributed computing middleware is usually de¬ 
signed to make remote procedure calls look as much like local calls 
as possible, in order to hide these issues, and the unwary developer 
is thereby tempted into falling foul of every one of Deutsch’s falla- 

This paper is specifically concerned with the second of Deutsch’s 
fallacies, that “latency is zero”. Good practice in the modular con¬ 
struction of centralized systems is to provide fine-grained inter¬ 
faces, so that each procedure deals with a single cohesive concern. 
But for a distributed system, this practice has to be weighed against 
the second fallacy: because of latency, it is much more efficient to 
provide coarse-grained interfaces, handling as much as possible 
with a single call and hence a single network round-trip. For ex¬ 
ample, Josuttis (2007) argues that whereas a local service dealing 
with customer records might provide separate methods to obtain a 
customer’s name, address, and payment details, a remote service 
ought instead (or additionally) to provide one compound method 



to obtain all three attributes at once. Similarly, Fowler (2002) de¬ 
scribes the Remote Facade pattern, which “provides a coarse¬ 
grained facade on fine-grained objects to improve efficiency over a 
network”. 

But coarse-grained interfaces cause a different problem, charac¬ 
terized by Deutsch’s third fallacy, namely that “bandwidth is infi¬ 
nite”. What if a client requires just a customer’s name and address 
and not the payment details? Calling separate methods for each at¬ 
tribute wastes a round trip. Calling the compound method to ob¬ 
tain three attributes then discarding one of them wastes bandwidth. 
Implementing a dedicated method to return just the two attributes 
needed by this particular client violates modularity and clutters the 
interface—the number of different attribute combinations is expo¬ 
nential in the number of attributes. What is the poor distributed 
system developer to do? 

One compromise presents itself: design the remote system to 
provide a fine-grained interface, promoting modularity, but also 
support a mechanism to batch up multiple small requests into a 
single compound request, minimizing latency. Of course, this only 
works in the case that later requests are independent of earlier 
responses. This idea has been rediscovered several times. Liskov 
et al. (1988) describe a stream abstraction for remote procedure 
calls, which among other features can batch together a sequence of 
small independent requests into a single message packet. Bogle and 
Liskov (1994) adapt this idea to batched futures, whereby cross¬ 
domain calls are simply collected together at the point of request, 
but not sent until the client actually needs the results. Ibrahim 
et al. (2009) introduce remote batch invocation as an extension 
to Java, automatically compounding remote method invocations. 
These recurring reinventions justify Fowler’s REMOTE FACADE 
pattern. 

More recently. Gill et al. (2015) describe the Remote Monad 
design pattern in Haskell, whereby remote procedure calls in the 
IO monad can be queued, as long as they are asynchronous and 
return void (“commands”); the queue is flushed and all requests 
sent when queueing a synchronous call or one that returns a result 
(a “procedure”). Gill et al. also point out that applicative functors 
are a more appropriate abstraction than monads for batched remote 
invocation, because they precisely capture the constraint that later 
requests must be independent of earlier responses. 

Still, Gill et al.’s construction is more ad hoc than it need be. 
They implement queueing from first principles, combining the IO 
monad for interaction with the State monad for maintaining the 
queue. Moreover, in order to batch together procedures in the ap¬ 
plicative style, they make essential use of Haskell’s lazy evaluation 
and rather sophisticated recursive do notation (Erkok and Launch- 
bury 2000). The contribution of this paper is to show that their so¬ 
phistication is unnecessary, and that the necessary definitions can 
essentially be obtained for free—specifically, by exploiting/iree ap¬ 
plicative functors. 





This paper is a literate Haskell program; the extracted code 
is available online at http: //www. cs . ox. ac. uk/ jeremy. 
gibbons/publicS$i5£ons/delivery. hs. 

2. Scenario 

In order to facilitate comparison, we adopt Gill et al. (2015)’s 
‘intemet-of-things toaster’ example. This is a device that can be 
instructed to display a message on a built-in screen, to toast for a 
certain amount of time, and to sense and return its current temper¬ 
ature: 

data Command :: x —> x where 
Say :: String —> Command () 

Toast v.Int —> Command () 

Sense:: () —> Command Integer 

Note the essential use of a generalized algebraic datatype: each 
Command includes its argument as part of its value, and expresses 
its return type via a phantom type index (Hinze 2003). 

The main point to be made with the choice of example is to con¬ 
trast the high-level, typed, computationally intensive capabilities 
available on the client side against the low-level, perhaps untyped, 
more limited capabilities on the server side. Nothing of significance 
in what follows would change if a different example were chosen— 
for example, one with some truly stateful server-side behaviour. 

2.1 Serialization 

We will need to serialize and deserialize commands for transmis¬ 
sion. For simplicity, we will use plain Strings as the wire format. 
Serialization is so straightforward that it can be derived automati- 

deriving instance Show (Command r) 

Deserialization is rather harder, because of the GADT: what type 
should be returned when deserializing a given string? We deliber¬ 
ately do not try to do anything too fancy type-wise here, because de¬ 
serialization of a command happens on the server side where there 
are limited capabilities. However, we can at least read the ‘name’ 
of a command: 

data Name = NSay \ NToast \ NSense 
deriving Show 

and return that, together with any remaining payload: 
readCommand:: String —> (Name, String) 
readCommand s = head $ 

[(NSay,s') ("Say"./) <- lexs] -H- 

[( NToast,s') j ("Toast",/) <—lexs ]~(+ 

[(NSense,s’) | ("Sense",/) <- lexs] 

Here, lex:: String -¥ [ (String, String) ] is a standard Haskell function 
to extract the first token from a string that is assumed to represent 
an expression. For example, 

readCommand (show ( Toast 3)) = (NToast, " 3 ") 

Meanwhile, back on the client side, if we already know the com¬ 
mand, we can use its type index to tell us what type of reply to 
expect from a response string, using the same polymorphic read 
function in each case: 

readReply:: Command r —> String —t r 
readReply (Say _) s = read s 
readReply (Toast ) s = read s 
readReply (Sense _) s = read s 

One could make explicit the association between commands and 
their names by lifting the type Name to a data kind (Yorgey et al. 


2012); but this does not seem to prevent all possible ways of 
mismatching requests and responses, so in the interests of keeping 
things simple we will refrain from making this refinement. 

2.2 Remote Procedure Calls 

We will communicate with our toaster by remote procedure calls 
over TCP. We factorize the code as follows. We represent the server 
behaviour as a function of type 

type ServerBehaviour = String —> 10 String 
It should accept a serialized request as its argument, and return 
a serialized response as its result, typically having I/O effects on 
the toaster in the process, but not itself performing any network 
interaction. We subject this function to a server-side wrapper 
server:: ServerBehaviour —> IO () 
that encapsulates the toaster’s network interaction. We identify 
a complementary wrapper encapsulating the client-side network 
interaction 

client:: String —> IO String 

which takes a serialized request as argument and returns a serialized 
response as result. 

Given these server and client wrapper functions, and a suitable 
argument ts:: ServerBehaviour representing the toaster’s behaviour, 
we can run the server program 
mainServer ::IO () 
mainServer = server ts 

on one machine (representing the toaster), and the client program 
mainClient:: String —> IO () 
mainClient s = do 

response <— client s 

putStrLn ("Received " -H- response) 
on another. The server and client wrappers are there solely to 
facilitate the network interaction; in particular, when mainClient s 
is run on the same machine as mainServer, then the combined 
behaviour should be the same as running 
do 

response <— ts s 

putStrLn ("Received " -H- response) 
without any network interaction. Since networking per se is not 
our primary interest, we relegate to Appendix A simple Haskell 
implementations of the server and client wrappers, and turn our 
attention to the ServerBehaviour. 

2.3 Individual Requests 

We now have the ingredients to send individual requests to the 
toaster. If we define the toaster’s behaviour for each of the three 
commands as follows: 

execSay:: String —t IO () 
execSay s = putStrLn s 
execToast ::Int -> IO () 
execToastn = do putStr ("Toasting. . . ") 
threadDelay (1000000 x n) 
putStrLn ( " done ! ") 
execSense:: IO Integer 
execSense = randomRIO (0,100) 

(for illustrative purposes, execSense simply picks a temperature 
uniformly at random between 0 and 100, rather than manipulat¬ 
ing actual hardware), then we can assemble these into the overall 
server-side behaviour: 



execCommand:: ServerBehaviour 
execCommand s = case readCommand s of 

( NSay ,/) —> do {r t— execSay (read s');return (show r)} 

(NToast,s') —» do {r «— execToast (read f)\retum ( show r )} 
(NSense,rf) —> do {r t— execSense:return (show r)} 
commandServer:: 10 () 
commandServer = server execCommand 
In light of our stated intention that the server side has only limited 
and low-level computational capabilities, we would typically not 
use Haskell to program it; we would use something lower-level, 
like C. Then commandServer should be thought of as a Haskell 
specification for the required C implementation. 

However, one might perfectly well use Haskell to program an 
internet client to interact with the toaster. For example, this client 
takes a single command, converts it to a string, sends it as a request, 
then reads the appropriate type of result from the response as 
determined by the command that was sent: 
commandClient:: Command r —y 10 r 
commandClient c = do 

r t— client (show c) 
return (readReply c r) 

Having started commandServer remotely, one can then interact 
with the toaster by invoking individual commands locally: 

♦ Main) commandClient (Say "Howdy doodly do!") 

♦ Main) commandClient (Toast 3) 

♦ Main) commandClient (Sense ()) 
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3. Free Monads 

We now return to the question of batching up multiple requests. As 
a first approximation, we can think of this as passing not a single 
command from the client for remote execution on the server, but a 
whole program built from such commands. Of course, this raises 
the question of whether it is reasonable to expect programs to be 
mobile in this way: should a toaster have the capability to run a 
program? This is indeed a worthy question, and we will return to it 
at the end of this section; but for the time being, let us suspend any 
disbelief. 

The standard technique for representing programs given a syn¬ 
tax of commands is to use free monads: 

data FreeMf a = Var a \ Com (f (FreeMf a)) 

For FreeM / to be a monad, we need/ to be a functor: 
instance Functorf =t* Monad ( FreeMf ) where 
return = Var 
Vara >=k = ka 

Com x k = Com (frnap (55>=fc) x) 

Informally, the free monad for a functor/ is given by trees with el¬ 
ements in the leaves and/-structures of children for internal nodes; 
the unit of the monad constructs a leaf, and the multiplication per¬ 
forms substitution. If/ is suitably .S'/iovvable, then so is FreeMf: 
deriving instance (Show (f (FreeMf a)),Show a) =t- 
Show (FreeMf a) 

The datatype Command has the right kind to be a functor, but 
because its type parameter is a phantom type, we cannot complete 
the definition—given a function/ of type r —> /, there is no general 
way to define fmapf:: Command r —y Command r'. However, we 
can make Command into a functor if we combine it with a function 
from the phantom type: 


data Action a = Mr.Action (Command r, r —y a) 
instance Functor Action where 
fmapf (Action (c,k)) = Action (c,f-k) 

(This can be seen as the embodiment of the dual of the Yoneda 
Lemma (Manzyuk 2013).) Now we have an appropriate Functor, 
we define Programs in terms of the corresponding free monad: 

type Program a = FreeM Action a 

We can now define single-step programs (what Plotkin and Power 
(2003) call generic effects) for each of the commands: 

effect:: Command r —y Program r 

effect c = do { Com (Action (c, Var ))} 

say::String — y Program () 

say s = effect (Say s) 

toast ::lnt-y Program () 

toast n = effect (Toast n) 

sense:: Program Integer 

sense = effect (Sense ()) 

and then we can write composite programs using do notation— 
both those in which requests are independent, like this straight-line 
program: 

straight:: Program () 

straight = do {say "heHo";toast 3 ;say "goodbye" } 

and those in which later requests depend on earlier responses, like 
this branching program: 

branch'..Program () 

branch = do {ft— sense: if f < 80 then toast 3 else say " hot" } 

But these programs are difficult to serialize and hence to distribute: 
a program like branch, with a sense command anywhere other than 
the final step, is in general infinitely branching. Put another way, 
there is no good way of defining a show function for Actions, and 
hence not for Programs either. However, if we restrict attention to 
finitary functors, we can—at least in principle—enumerate all the 
branches: 

data ActionF a = Mr. (Bounded r,Enum r) => 

ActionF (Command r,r—y a) 
instance Show a -> Show (ActionF a) where 
show (ActionF (c,k)) = show c- H-" "-H- 

show [show (kr) \r<— [minBound.. maxBound] ] 
type ProgramF a = FreeM ActionF a 

Here, the Haskell type class Bounded denotes types with a minBound 
and maxBound, and Enum denotes types with the succ function 
needed for the notation. 

We cannot support the infinitary Sense command that returns an 
Integer, because this type is not Bounded ; but we could support a 
finitary sensing command, returning a value from an enumeration 
instead: 

data Temperature = Low \ Medium \ High 
deriving (Show, Read, Enum, Bounded) 
data CommandF:: x — y x where 
SayF :: String — y CommandF () 

ToastF ::Int —y CommandF () 

SenseF :: () —y CommandF Temperature 

We can now serialize a finitary program to send to the server; what 
should the server do when it receives it? First it should determine 
whether the program is a plain Var or a Composite: 



readFirstFreeM w String —> (Bool,String) 
readFirstFreeM s = head $ 

[(True,s') | ('%!*,/) -H- 

[ (False, s') j ("Com",/) •(—/ears] 

If the program is a Vbr, then the remaining input is the value to be 
returned. Otherwise, the server should read the first command; de¬ 
pending on what command this is, the server should read the appro¬ 
priate type of argument, and execute that command. Finally, based 
on the result of executing the command, the server should pick the 
next branch to follow. In particular, for the SenseF command, there 
will be three continuation branches, one for each Temperature, and 
the server reads three serialized subprograms and picks one of 

execProgram:: String —> IO String 
execProgram s = case readFirstFreeM s of 
(True,s') —> returns' 

(False, s') —> case readCommandF s' of 
(NSayF,s") —> do (m,s'") t— readOne s" 
execSaym 

execProgram (head (read s'")) 
(NToastF,s") — > do (n.s'") <— readOne s" 
execToast n 

execProgram (head (read s'")) 
(NSenseF,s") —> do (Q,s"') <— readOne s" 
t <— execSenseF 

execProgram (read s'" ! \fromEnum t) 
Here, readOne is a simple wrapper: 

readOne:: Read a => String —y 10 (a, String) 
readOne s = return (head (reads s)) 

(Note that the three Composite cases of execProgram are really of 
the same form; for example, the Say command returns a () result, 
and fromEnum () = 0, and so that case could have been written 
instead 

do (m,s'") <— readOne s" 
t <— execSay m 

execProgram (read s'" ! \ fromEnum t) 

But we have stuck with the clearer and simpler but less regular 
version above.) Now we can run 
programServer:: IO () 
programServer = server execProgram 
on the server, and 

programClient :: (Show a,Read a) => ProgramF a —> IO a 
programClientp = do {r t— client (showp);return (read r )} 
on the client, and pass a whole program for remote execution. 

Still, one might argue that it is a lot to expect of a toaster— 
even an intemet-of-things toaster—for it to be able to parse nested 
serialized commands, select the appropriate branch, and so on. This 
brings us back to the question at the start of this section, and the 
discussion in the introduction: frameworks for batched requests 
typically insist that later requests should be independent of earlier 
responses; that is, that there should be no branching in a batch. The 
ProgramF type allows branching, so is too general. We show next 
how to enforce the no-branching constraint. 

4. Free Applicative Functors 

Free monads are the standard technique for capturing syntactic de¬ 
scriptions of programs over a particular signature of primitive ac¬ 
tions. However, as we have seen, such programs are typically too 


general to be considered appropriate as batched requests for re¬ 
mote execution. In particular, it is arguably unreasonable to expect 
a mere toaster to be able to interpret a branching program. More¬ 
over, branching programs can quickly become very large things to 
transmit, especially if individual commands have high out-degree. 
We already had to dispense with the infinitary Sense that forms 
a Command Integer in favour of the finitary SenseF that forms a 
CommandF Temperature ; but even then, while an out-degree of 3 
may be reasonable, an out-degree of 100 is probably not. 

These arguments all lead us to the conclusion that branching 
programs are inappropriate for batched requests, and that we should 
restrict attention to straight-line programs. It is fine for individual 
commands to return results, even results drawn from infinite types 
like Integer, but we should ensure that subsequent commands in the 
batched request are oblivious to those results. Instead, a sequence 
of requests is transmitted to the server, invoked one after the other 
but independently, yielding a sequence of results that is returned 
to the client, and those two sequences are combined to match up 
individual requests with the corresponding results. 

This independence of later steps on earlier results is precisely 
what characterizes the distinction between monads and applicative 
functors (McBride and Paterson 2008). So let us explore what hap¬ 
pens if we try to batch up commands using free applicative functors 
rather than free monads. There are several equivalent definitions of 
free applicative functors (Capriotti and Kaposi 2014), of which we 
pick the following: 

data FreeA :: (x —> x) — > x —> x where 
Pure :: a —> FreeA f a 

Morewf (b—r a) —¥ FreeAf b —> FreeAf a 
Informally, a value of type FreeA f ao is a right-nested sequence of 
the form (fs 0 , (fsi, (..., (fs n _i,x)...))), where n ^ 0, each element 
fsj has type / (a [+ \ —> a,-), and the rightmost element x has type 
a n . Note that the type variable h in the type of More is implicitly 
existentially quantified, as are each of the a, (for i > 0) above. 

Provided that / is a functor, that datatype can be given the 
structure of an applicative functor, as follows: 

instance Functorf => Applicative (FreeA f) where 
pure = Pure 
Pure f ®y =fmapf y 

More hx®y = More (finap uncurry h) (pure (,) ® x ® y) 
Now we no longer need to insist that result types of commands 
are bounded and enumerable, because we are no longer going to 
enumerate them—they need only be readable: 

data ActionA a = Mr.Read r => ActionA (Command r,r—> a) 
This ActionA type is straightforwardly a functor, as Action was, 
instance Functor ActionA where 
finapf (ActionA (c,k)) = ActionA (c,f-k) 
and so we can assemble applicative programs from it: 

type ProgramA a = FreeA ActionA a 
We can make single-step programs for each of the commands, 
much as before: 

effectA:: Read r => Command r —> ProgramA r 

effectA c = More (ActionA (c, Xr () —> r)) (Pure ()) 

sayAv. String —> ProgramA () 

sayA s = effectA (Say s) 

toast A :: Int —> ProgramA () 

toastA n = effectA (Toast n) 

senseA:: ProgramA Integer 

senseA = effectA (Sense ()) 



Here’s a straight-line program that senses the temperature, toasts 
for a bit, and senses the temperature again. Later commands are by 
construction independent of the results of earlier ones. 
straightA :: ProgramA {Integer, Integer) 

straightA = pure {Xt () / —>■ (t, /)) © senseA © toastA 3 © senseA 
We still can’t serialize a whole program; in particular, we can’t 
serialize arbitrary pure functions such as Xt () f —> {t, t') above. But 
crucially, now we don’t need to—all we need to do is to serialize 
the commands, not the specific mechanism for collating replies: 
serializeA:: ProgramA a —t [String] 
serializeA {Pure _) ="[] 

serializeA (More {ActionA {c, _)) p) = show c: serializeA p 
If we have remembered the program, and retrieved a sequence of 
responses, we can essentially zip the two together to match up 
individual requests with their responses; 

deserializeA ■.■.ProgramA a —> [String] —> a 
deserializeA {Pure a) [ ] = a 
deserializeA {More {ActionA ( c,k )) p) {s:ss) 

*' • ’5= k {readReply cs) {deserializeApss) 
Now all our server needs to be able to do is to unpack a flat 
sequence of requests, execute the requested commands one after 
the other, and pack up a flat sequence of responses: 
execStraight:: String —t IO String 
execStraight s = do let reqs = read s 

resps t— sequence {map execCommand reqs) 
return {show resps) 

This can be deployed via 
straightServer ::IO () 
straightServer = server execStraight 
straightClient:: ProgramA a^rlO a 
straightClientp = do r <— client {show {serializeA p)) 
return {deserializeA p {read r)) 

This behaviour is, we argue, not too much to expect of a toaster. 

5. Remote Monads for Free 

Let us compare our story to Gill et al. (2015)’s Remote Monad 
design pattern, which inspired this paper. They do not use free 
monads or free applicative functors; instead, they build the batch¬ 
ing mechanism from scratch. They distinguish between an asyn¬ 
chronous Command, which returns no result, and a synchronous 
Procedure r, which returns a result of type r; these datatypes to¬ 
gether are analogous to our Command r, since we make no distinc¬ 
tion between synchronous and asynchronous requests. 

Their remote Device is essentially a String —> IO r function, 
where the return type r is () for asynchronous commands and String 
for synchronous procedures; it is analogous to our execCommand. 
Their individual Command and Procedure requests can be seri¬ 
alized and sent to a Device by their send function, analogous to 
our commandClient. Their ‘strong remote monad’ Remote is a 
combination of ReaderT Device for accessing a particular device, 
StateT [Command] for maintaining a buffer of unsent commands, 
and IO for actual remote communication. Individual Commands get 
appended to the buffer but not invoked immediately. An individual 
Procedure is combined with any buffered Commands into a Packet: 

data Packet r = Packet [Command] (Procedure r) 
and it is only Packets that are sent across the wire. (There is a 
separate function to flush the buffer; this could have been avoided, 
if they had provided a skip:: Procedure () instead.) 


Their datatype Packet is a simplification of the free applicative 
functor. It represents a non-empty sequence of requests, where 
the last is synchronous and the others all asynchronous; but it 
is built from scratch. By construction, later requests in a packet 
are independent of the results of earlier ones—indeed, the earlier 
ones have no results on which to depend. But this is a stronger 
constraint that necessary; as we have seen, it would be fine to 
allow intermediate requests to return results, so long as they do not 
influence later requests. 

Gill et al. do introduce a ‘strong remote applicative functor’, 
motivated by the same observation that we make that “applicative 
functors are fundamentally better suited to remoteness than monads 
are: subsequent applicative computations cannot depend on the 
results of prior computations”, allowing them to batch multiple 
Procedures into a single Packet. However, they make essential use 
of lazy evaluation and recursive do notation in order to match up 
responses with their requests (their send function is now cyclic). We 
show that these language features are unnecessary; our approach, 
with free applicative functors, will work just as well in a simple 
eager language as a sophisticated lazy one. 

Neither we nor Gill et al. provide implicit batching of separate 
requests. In both cases, the programmer has to explicitly partition 
the program’s requests into batches, and it is only the actual assem¬ 
bly of each group of requests into a single batch that happens more 
or less for free. Other approaches are similar in this respect; for 
example, Ibrahim et al. (2009) introduce a batch construct into 
Java in order to explicitly group requests into batches, and Cook 
(2010) declares that “although the result itself is elegant and useful, 
what is more significant is the realization that the original problems 
[of implicit batching] cannot be solved using existing programming 
language constructs and libraries. This work calls into question our 
assumption that general-purpose programming languages are truly 
general-purpose”—unless presumably they have some kind of re¬ 
flection mechanism or meta-object protocol. 

6. Conclusions 

To summarize: remote procedure calls benefit from batching of in¬ 
dependent requests in order to reduce round-trips; batched requests 
are essentially serializations of small programs; the traditional tech¬ 
nique for serializing programs is to use free monads; free monads 
are really too liberal for this problem, because they accommodate 
(possibly infinitary) branching; free applicative functors, however, 
represent serialized straight-line programs; free applicative func¬ 
tors therefore have precisely the right restrictions for batching re¬ 
mote requests. 

We have discussed the relationship with the Remote Monad 
pattern (Gill et al. 2015); our novel contributions are that free con¬ 
structions are the essence of program serialization, and that batch¬ 
ing is fundamentally about applicative functors rather than monads. 
Marlow et al. (2014) present something like Gill et al.’s ‘strong re¬ 
mote applicative functor’, but they too build from first principles 
an analogue of the free applicative functor (their datatype Fetch). 
They also describe a proposed Haskell extension ApplicativeDo 
(Marlow 2015), whereby applicative computations can be writ¬ 
ten in the monadic do notation, and the concurrency inherent in 
independent requests can be reconstructed. This has just been in¬ 
corporated into GHC (GHC 8.0), and it will be a very convenient 
provision—our applicative program straightA in Section 4 is much 
less clear than the similar monadic program straight in Section 3. 
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A. Server and Client Wrappers 

The server and client wrappers discussed in Section 2.2 are mi¬ 
nor modifications of the example shown in the documentation for 
the Network.Socket.ByteString library (Tibell). To use these defini¬ 
tions, we need the following imports: 

import Control.Monad {unless,forever) 
import Network.Socket hiding ( recv ) 
import Network.Socket.Bytestring {recv, sendAll) 
import qualified Data.ByteString as S 
import qualified Data.ByteString.Char8 as C 
The server is set up to listen on port 3000: 
server:: ServerBehaviour -a IO {) 
server f = withSocketsDo $ do 
{addr. _) <— getAddrlnfo 

{Just {defaultHints {addrFlags = [AIJPASSIVE ]})) 
Nothing {Just "3000") 

,v <— socket {addrFamily addr) Stream defaultProtocol 
bindSocket s {addrAddress addr) 
listen s 1 
forever $ do 

{conn, _) t— accept s 
talkf conn 

where talkf c repeatedly reads up to 4096 bytes from connection c, 
converts the corresponding bytestring to a string, applies/ to it, and 
sends the result back, until it reads null: 

talk:: {String -A IO String) -A Socket -A IO () 
talkf conn = 
do req <- recv conn 4096 
unless {S.null req) $ do 
resp t—/ {C.unpack req) 
sendAll conn {C.pack resp) 
talkf conn 

And for the client, we have 
client:: String -A IO String 
client request = withSocketsDo $ do 
{addr: _) <— getAddrlnfo 
Nothing {Just "127.0.0.1") {Just "3000") 

,v t— socket {addrFamily addr) Stream defaultProtocol 

connect s {addrAddress addr) 

sendAll s {C.pack request) 

response <— recv s 4096 

sClose s 

return {C.unpack response) 

The hard-wired IP address (here, for demonstration purposes, the 
loopback address "127.0.0.1") and port ("3000") in client 
are for the machine on which the server is running and the port on 
which it is listening. 








